-
-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modules/output: produce empty files by default #1909
Conversation
Thanks! I'd already looked at doing this in #1889, however since that one is larger in scope and unfinished it's better to have this merged sooner than later! It's also good to have tests, which I hadn't implemented in #1889. Would you mind looking over how I'd done it in that other PR to see if there's any elements you'd like to incorporate in this one? E.g. it probably makes sense to move Not too important as those things may expand the size/scope of this PR unnecessarily making it harder to review. But worth a quick look. |
Your implementation is better, because it doesn't output empty lines. I like it more. But I intentionally didn't rip it off, because I wanted something simple to get started (and functional) + tests. And since you already implemented a better version, I thought that I don't need to make it perfect, just functional, and you'll easily rebase to it later. But if you think that it's better to include your version here, I probably can extract it from there. |
dc71fb6
to
d1e2ecf
Compare
I don't mind too much either way. There's certainly value in keeping this PR simple as you said. |
73c34ca
to
13b3fc3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Just reviewing the treewide mkIf commit)
- This would be better off in a dedicated PR, IMO.
I don't see how it relates to this one? - There's a typo in the commit message (
treeside
->treewide
) - Some stuff is either deliberately not using mkIf or is less readable, especially string concatenation.
I rewrote it completely. See if it's OK. Also I replaced a couple of global instances of Before:
After:
Notice that there is no empty definitions by default. But similar cases with empty definitions are still present in some of the plugins, although they are guarded by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This review is for the other (non-mkIf) changes)
Looks good, mostly just minor nits!
I'll check comments tomorrow. Please decide if a second commit removing empty lines from outputs in a various places is wanted or not. |
After reading your replies I agree it makes sense in this PR, but it would benefit from a commit message that explains the motivation behind the change, as I was clearly confused 😉
I'm happy to keep it, though I think empty lines in config that is defined anyway aren't as bad as non-empty lines relating to unconfigured stuff. |
13b3fc3
to
9430227
Compare
Since other PRs are merged, tests are passing. |
9430227
to
5329e98
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for your efforts and your patience explaining things to me and debating various pros/cons!
I think this change will be appreciated by many!
@nix-community/nixvim any final suggestions before merging?
EDIT: tests
all pass locally on x86_64-linux.
5329e98
to
d4f37e5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after a rapid glance.
I trust @MattSturgeon for the details.
Thank you very much @stasjok for this great work and for addressing the detailed review !
@Mergifyio queue |
🛑 The pull request has been merged manuallyThe pull request has been merged manually at 9317537 |
The motivation for this change was to avoid generating empty config sections like vim.cmd([[ ]]) To make a config generation cleaner several helper functions introduced: * `hasContent` have been moved to helpers * `concatNonEmptyLines` joins strings (which has content) separated with newlines * `wrapVimscriptForLua` wraps a lua string for using in Vimscript, but only if the string has content, otherwise empty string is returned * `wrapLuaForVimscript` wraps Vimscript for using in lua, but only if the string has content, otherwise empty string is returned Added tests: * testing that all possible config sections are present in the final generated config * testing that the config files generated by empty `files` definitions don't have any content in it
Problem: Some modules are setting empty strings to extraConfig* options with the intention to not generate any config. But empty strings are also values, so they are still concatenated in the final value of extraConfig* options. This results in a multiple empty strings in extraConfigs. Solution: Avoid using optionalString when setting values to extraConfig* options. Use mkIf instead. This commit also fixes mkIf condition in autocmd module. `mkNeovimPlugin` is a special case. To avoid evaluating caller's arguments mkMerge/optionalAttrs pattern is used instead.
d4f37e5
to
0f3edf0
Compare
This PR removes empty
block from config.
I know that this is already handled by #1889, but I've added tests to make sure that this is the behavior. Also I added the test to make sure that all extraConfigs are outputted.
This also changes various places in other modules with the intention of not setting
extraConfig*
options to empty strings (more specifically whitespace only strings).NOTE: The tests will fail until #1906, #1907 and #1908 are merged.